• Bump version from 0.4.13 to 0.4.14
• Update changelog with 'guard' hook installation feature

Version number increment

• Update project version from 0.4.13 to 0.4.14

pyproject.toml

Add version 0.4.14 changelog entry

• Add entry for version 0.4.14 describing 'guard' hook installation flow for Claude Code and Cursor

CHANGELOG.md

Description

The project version was bumped to 0.4.14 in pyproject.toml, but uv.lock still records the editable
package version as 0.4.13, leaving the lockfile out of sync with the release version. This will
cause anyone running uv sync/lock to get a changed lockfile (and potentially inconsistent local
metadata), which is especially risky in a version-bump PR.

Code

pyproject.toml[3]

+version = "0.4.14"

Evidence

pyproject.toml declares 0.4.14, while the checked-in uv.lock still pins the local editable package
as 0.4.13, demonstrating the lockfile was not regenerated after the bump.

pyproject.toml[1-4]
uv.lock[1954-1957]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`pyproject.toml` was bumped to version `0.4.14`, but the committed `uv.lock` still contains the project package entry at `0.4.13`. This indicates the lockfile wasn’t regenerated after the version bump.

### Issue Context
This repo uses `uv sync` in the Makefile for CI/dev flows, and the lockfile is checked in. A version-bump PR should keep `uv.lock` consistent to avoid unexpected lockfile diffs and reproducibility surprises.

### Fix Focus Areas
- pyproject.toml[1-4]
- uv.lock[1954-1957]

### Suggested fix
1. Regenerate the lockfile using your standard workflow (e.g., `uv lock` or `uv sync` so it updates `uv.lock`).
2. Commit the updated `uv.lock` showing `snyk-agent-scan` at `0.4.14`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools